The invention relates to computer systems, and more particularly to a method and mechanism for accessing and managing data in a database system.
In database systems, a “transaction” normally refers to an atomic set of operations performed against a database. The transaction may access, create, modify, or delete database data or database metadata while it is being processed. A “commit” occurs when the transaction has completed its processing and any changes to the database by the transaction are ready to be “permanently” implemented in the database system. Because the transaction is atomic, all actions taken by the transaction must be committed at the same time.
Transaction log records can be maintained in a database systems, e.g., to allow suitable recovery operations in the event of a system failure or aborted transaction. Some common problems that could cause a system failure or aborted transaction include hardware failure, network failure, process failure, database instance failure, data access conflicts, user errors, and statement failures in the database access programs (most often written in the structured query language or SQL).
Different types of transaction log records can be maintained in a database system. A common transaction logging strategy is to maintain “redo” records that log all changes made to the database. With “write ahead logging”, each change to data is first recorded in the redo log, and only afterwards is that change actually made to the database block corresponding to the changed data. This protects against the situation when a system failure occurs and the version of the database data that is immediately restored from disk does not accurately reflect the most recent state of the database. This may occur because of changes to the data that have only occurred in cache, and have not been recorded to disk before the failure. If the redo log has been properly maintained for these cache-only changes, then recovery can be performed by applying the redo records to roll the database forward until it is consistent with the state that existed just before the system failure.
Another type of log record that may be maintained is the “undo” record, which can also be referred to as “rollback” segments. Undo records contain information about database actions that should be undone during certain database operations. For example, if the rolling forward process during recovery has applied uncommitted changes to the database, then undo records can be applied to remove uncommitted changes, thereby ensuring that only committed changes exist in the database after recovery. In addition, if a transaction is aborted, then undo records can be applied to return the database to its pre-existing state from prior to the aborted transaction. If a database uses multi-versioning to allow different transactions to view database data from different points in time, then undo records can be used to create multiple versions of the database that are consistent with the different points in time. An approach for implementing undo and redo records is disclosed in co-pending U.S. application Ser. No. 09/748,408, entitled, filed Dec. 22, 2000, which is hereby incorporated by reference in its entirety.
In conventional systems, a committed transaction comprises a set of one or more permanent changes that are made against a set of records in a database system. While different versions of the database records may be viewable under certain circumstances, since the committed changes for a transaction are normally permanent, the transactions themselves are not normally reversible. This presents a problem if a data error in a transaction is identified after the given transaction has already committed. Conventional database systems do not include built-in mechanisms to undo or compensate for the changes made by a committed transaction.
Some database systems allow an archived version of a database system to be restored to a particular point in time, usually by restoring the entire database as of the time that the “back up” archive was made. However, this approach restores an entire database, even though only a small set of one or more transactions may need to be undone or compensated for to correct a data error made by the transactions. This is a highly inefficient approach if only a relatively small number of changes or transactions must be corrected.
Accordingly, the present invention provides a method and system for undoing, reversing, or compensating for a committed transaction in a database system. Also disclosed is a method and system for identifying the one or more transactions that have modified or created an object, such as a row of data, in a database system. Further details of aspects, objects, and advantages of the invention are described below in the detailed description, drawings, and claims.